Subject: Network Name in ACTLU

From: "Jim Fletcher ((919) 254-5929)" <[email-masked]>
Date: Mon, 27 Nov 95 07:18:39 EST

Ref:  Your note of Wed, 22 Nov 1995 21:16:29 -0500

With regards to the LU and PU names in ACTPU and ACTLU, these are sent to
NCP and then stripped in most (all?) cases. The names were needed for
NCP to do some verification/correlation for dynamic updates, but as you
state we were afraid that some brain dead (and there are lots of them) PU
would croak if we sent them to it.

I looked at adding capabilities indicators to ACTPU a while back to support
this and it wasn't "simple" because of the current formats. If I remember
right I had to go back to XID to indicate support, because I cannot extend
the ACTPU with a new control vector because extending it will cause some
boxes to croak as well. When I discussed adding this to XID, it was not
well received.

My original intent was to be able to provide the PU and LU names to
smart PU2s so that they could display the information on their screens for
PD purposes.

Anyhow, its a problem that looks easy to solve, but because of "old iron"
becomes more difficult.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 28 Nov 1995 12:46:00 -0500

>would croak if we sent them to it.

It is, of course, understandeable that a PU 2.0 implementor might choose to
get upset at the additional vector, since IBM chose not to document its
existence!  However SC30-3112 did not document any length check on ACTLU or
ACTPU, so anyone who did implement such a check was exceeding the
architecture specification.

I notice that the DLUR specification describes removing the CVs from the
ACTPU and ACTLU, and its implementation was based on the NCP BF, so you are
probably right that they are always removed, although I could have sworn
that the DDDLU specification required the CV on the ACTLU.  I can't find my
copy of the DDDLU specification, and there does not appear to be a copy
on-line anywhere.

>boxes to croak as well. When I discussed adding this to XID, it was not

There is also the case of a leased line SDLC or X.25 PVC in which there is
no XID exchange.

>Anyhow, its a problem that looks easy to solve, but because of "old iron"

So at present the only way a node can obtain this information is to come up
as an APPN EN/NN and establish a DLUR-DLUS pipe to implement its DLU
support.  Seems like a lot of work just so the implementors of those
hypothetical brain-dead PU 2s can get a free ride.   Considering the
enormous value of being able to correlate network management in the two
domains, can anyone suggest steps which we can take?